三天後開場，手上已經有一個網站

七月活動日前三天，IMS 有了第一個 commit。七月二十四日場佈、二十五日開場，留給開發與測試的時間只有幾天。

三十四位工作人員原本就有一個排班網站。另一位主辦把資料整理好了，選名字就能看每一場任務，前一年也靠這個網站完成活動。

但到了會場，大家忙著移動、處理事情，手機放在口袋裡，很容易忘記打開網站確認下一場任務。查詢的工具已經有了，缺的是在對的時間提醒人去看。

「讓工作人員及時收到任務提醒」成了這個 App 的核心目標。 本地通知、Widget 和 Live Activity，都是沿著這個目標選出來的功能：讓人少一步操作，也能注意到接下來的任務。

從這篇開始，我會回看 IMS 從網站資料做到 TestFlight 的過程。先從動手前的判斷開始：既然網站已經能用，為什麼還需要一個 App？

先用四個問題，確認這件事值得做

寫程式之前，我會先確認兩件事：為什麼要做，以及用什麼方式才能解決問題。你也可以把它們稱為策略（Strategy）和探索（Discovery）。

第一輪先回答四個問題，每題盡量用一句話說清楚：

第一題要寫出使用者遇到的困難。「做一個工作人員 App」只描述了要做的產品，還沒說明它為什麼有用；「工作人員會錯過任務」才讓後面的功能有了判斷依據。

第三題也不能省。知道現有網站已經能查排班，才知道 App 應把力氣放在提醒，而不是重新做一套資料管理系統。

現狀還會帶出限制：工作人員裡有 Android 使用者，這次卻只做 iOS。因此網站要保留，讓沒有安裝 App 的人仍然有查詢管道。這也需要寫進計畫。

MVP 的「最小」，要回到問題來判斷

MVP 可以理解成「足以驗證核心價值的最小可用版本」。難的地方在於，我們很容易把每個想做的功能都說成必要。

我會做一個簡單的練習：如果功能只能留一半，哪些一定要留下？ 這不是要求數量剛好減半，而是逼自己排出優先序。

IMS 想做的項目包括任務表、通知、Widget、Live Activity、現場全覽和多語系。第一批先留下任務表、通知與 Widget：任務表提供查詢，通知主動提醒，Widget 讓使用者快速看見當下資訊。

Live Activity 也能幫助查看進度，但第一版已有提醒和快速查詢的管道，可以先排在後面。「現場全覽」服務的是查看多人任務的需求，也可以和個人提醒分開交付。

當時的計畫把工作分成 Build 1 和 Build 2：第一批先上傳，等待審核時再做第二批。這樣即使後續功能來不及完成，仍有一個能交付的版本。

後來評估進度與 Live Activity 的風險後，兩批合併成一個版本上傳。拆分仍然有用：它讓我在開工時就知道，哪些是今天必須完成的，哪些可以往後放。

做了之後，才發現「選名字」有兩種意思

四題回答完，仍可能漏掉使用情境。IMS 當天下午兩點四十一分有一個 commit，叫做「explicit activation switch」，就是在修正一個先前的假設。

原本的設計把「選名字」當成「這是我」。選了誰，通知、Widget 和 Live Activity 就都跟著那個人走。

但使用者也可能只是想看看別人的行程。這時，查詢另一個人的任務，卻把自己原本的提醒換掉了。

後來的做法是把兩件事拆開：選名字只負責檢視；按下「這是我・開啟提醒」的開關，才設定提醒對象。晚上九點五十二分，又加入了可依時段查看所有人分組位置的「現場全覽」。

回頭看，這些修改提醒我：同一位使用者，也可能在不同時候有不同目的。 他有時要看自己的下一場任務，有時要查看其他人的安排。光寫「工作人員」四個字，還不足以說明這個差別。

四題的用途，是讓你先有可檢查的假設。實作或試用時出現新證據，再回來調整，而不是把第一版答案當成永遠不變的規格。

今天要做的一件事：檢查 ticket 的第一版範圍

拿 Day 6 的 ticket，或你手上任何一個想做的功能，整理成設計文件的第一頁：

1. 四題各寫一句話。 第一題先描述困難，不急著寫頁面或按鈕；第四題再說要交付哪些功能。
2. 列出所有想做的項目，試著只留一半。 每一項都要能說明它如何幫助解決第一題的問題。延後的項目附上原因。
3. 寫出這次服務不到的人。 例如 Android 使用者、沒有網路的人，或不願安裝 App 的人，再決定要保留什麼替代管道。
4. 列出一個最大的交付風險。 它可能是審核時間、資料是否取得，或某個技術環節尚未驗證。

可以請 AI 扮演會追問的產品經理，逐項檢查：「這個功能解決了哪個問題？少了它，第一版還能不能用？」你的工作是判斷理由，而不是照單接受它刪掉的項目。

如果前一篇已經完成釐清，這一步直接檢查既有結論即可，不必重新訪談。

新人最常在這一步犯的錯

一有點子就開始做。 時間越短，越需要先確認哪些工作能直接解決問題，否則很容易把時間花在次要功能上。

用功能清單代替目標。 「有 A、B、C 的 App」還沒說明價值。逐項問：使用者為什麼需要它？

跳過現有做法。 不知道使用者現在如何處理問題，就很難判斷新工具究竟改善了什麼。

每個功能都列為第一版必要項目。 回到核心問題，分出必要、加分和可以延後的項目，並保留延後原因。

把初步答案當定案。 「選名字就是本人」看起來合理，遇到查看他人行程的情境就不成立。發現新資訊時，要願意修正假設。

本篇可帶走的檔案

把下面的模板存成 design-doc-第一頁.md。它用來整理方向，也能指出後續還需要釐清的決策。

# <專案／功能名>

## 四個問題

- 要解決什麼問題：<先描述使用者的困難>
- 給誰用：<對象與使用情境>
- 現在怎麼處理：<既有工具或替代做法>
- 第一版最少交付什麼：<能解決核心問題的功能>

## 功能取捨

| 想做的項目 | 保留／延後 | 理由：如何對應核心問題 |
|---|---|---|
| | | |

## 本次不做

- <項目，以及為什麼不是現在做>

## 這次服務不到的人

- <對象，以及保留的替代管道>

## 最大的風險與對策

- 風險：
- 對策：
- 尚待確認的前提：

IMS 當時最擔心的是審核時間超過可用的等待時間，因此把「儘早上傳可用版本」列為優先事項。風險寫清楚之後，第一版的範圍才有取捨依據。